The great debate between unmanaged and managed solutions rages on. This discussion started when solutions was first introduced in Dynamics CRM 2011. Many people go the route of unmanaged being burned by managed; each person with their own battle scars.
Personally I’ve been burned by unmanaged which makes on the managed side of the fence. It hasn’t been easy along the journey of these solutions but with the changes introduced in Dynamics CRM 2016 around patching and being able to actually remove technical debt or depreciated fields from a managed solution made the viability much higher in my opinion.
It’s worth considering Microsoft’s view point of managed solutions in every environment past development organizations. It can be easily viewed in the new v9 solution changes happening at the platform level. As the CRM product family has been expanding over the past few years we’ve seen the sales & service & marketing split into separately SKUs and available individually now. This has been done through managed solutions and Microsoft’s ability to layer them properly.
As an example of this I simply created a new solution and added the out of the box Account entity and exported it as unmanaged. When looking at the solution file it shows every dependency for the account entity and what solutions it comes from. A few sample are:
<MissingDependency>
<Required key="26" type="1" schemaName="territory" displayName="Territory" solution="msdynce_AppCommon (9.0.4.0022)" />
<Dependent key="27" type="10" schemaName="msdyn_territory_account_ServiceTerritory" displayName="msdyn_territory_account_ServiceTerritory" parentSchemaName="account" parentDisplayName="Account" />
</MissingDependency>
<MissingDependency>
<Required key="28" type="1" schemaName="bookableresource" displayName="Bookable Resource" solution="msdynce_Scheduling (9.0.0.0)" />
<Dependent key="29" type="10" schemaName="msdyn_bookableresource_account_PreferredResource" displayName="msdyn_bookableresource_account_PreferredResource" parentSchemaName="account" parentDisplayName="Account" />
</MissingDependency>
<MissingDependency>
<Required key="30" type="1" schemaName="msdyn_taxcode" displayName="Tax Code" solution="FieldService (7.4.0.74)" />
<Dependent key="31" type="10" schemaName="msdyn_msdyn_taxcode_account_SalesTaxCode" displayName="msdyn_msdyn_taxcode_account_SalesTaxCode" parentSchemaName="account" parentDisplayName="Account" />
</MissingDependency>
<MissingDependency>
<Required key="32" type="2" schemaName="name" displayName="Territory Name" parentSchemaName="territory" parentDisplayName="Territory" solution="msdynce_AppCommon (9.0.4.0022)" />
<Dependent key="27" type="10" schemaName="msdyn_territory_account_ServiceTerritory" displayName="msdyn_territory_account_ServiceTerritory" parentSchemaName="account" parentDisplayName="Account" />
</MissingDependency>
This gives us a bit of an inside view on solutions being used by Microsoft like “msdynce_Scheduling (9.0.0.0)” and “msdynce_AppCommon (9.0.4.0022)”. It’s really interesting how we’re able to see how they are splitting up the platform to enable different product offerings. It also shows the complexities in doing this with all of the out of the box entities. Needless to say V9 seems to be the first time we’re able to look around a bit more and understand where the platform team is coming from.
Hope you found this interesting because I sure do.